@theurich @billsacks
I looked at the failure and it's an issue I've seen before and I still approve this PR with this failure. There was an issue for it but it was closed without resolving.

20240910 215612.746 INFO             PET4  FAIL  Check time delay on non-blocking Component D Finalize/wait, ESMF_CompTunnelUTest.F90, line 1283:  Incorrect time delay
20240910 215612.746 INFO             PET4  delayTime (wait) =    2.9923109999999973

What's happening is that the time between ESMF_GridCompFinalize and ESMF_GridCompWait is less 3 seconds but the test assumes it will take greater than 3 seconds. Mac OS systems are finishing too quickly!

A possible solution could be to change the test to be something much smaller, like 1 second. I'm not sure why it's 3 seconds.

There are several reasons the CompTunnelUTest can fail. #237 discusses the socket issues. Here it is a timing issue - which is different.
There is a call to ESMF_VMWtimeDelay with 3 seconds in the test. The 3s are set by macro SLEEPTIME. For some reason either the clock precision is not determined correctly or there is some drifting of the clock or the WtimeDelay.. but just sometimes. I guess we could build in a larger tolerance than just 2x the clock precision. But it is a strange thing why Macs would need that.

@theurich
Okay, I see. I did think it was odd that finalize was expected to take longer than 3 seconds but now I see the call to ESMF_VMWtimeDelay. I assume that the ESMF_VMWtimeDelay calls sleep under the hood? It doesn't seem possible that the time between ESMF_VMWtime calls is less than 3 seconds. So I assume there's something going on within the system. I believe the runners are VMs so it's possible that the VM server messes around with the system clock?